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ABSTRACT 

The mission operations system is one of 
the more significant drivers of the cost 
of the mission operations and data 
analysis segment of missions. In large 
or long-lived projects, the MOS can also 
be a driver in total mission cost. 

Larger numbers of missions, together 
with an increasingly cost-conscious 
environment, dictate that future 
missions must more strictly control 
costs as they perform to their 
requirements. It is therefore prudent 
to examine the conduct of past missions 
for ways to conserve resources. 

In this paper we review inputs made to 
past projects' "lessons-learned" 
activities, in which personnel from 
past projects (among other things) 
identified major cost drivers of MOSs 
and considered how economies were or 
might have been realized in both 
design and performance of their MOS. 
Common themes among four such 
reviews are summarized in an attempt 
to provide suggestions for cost 
reduction in future missions. 

Key Words: Mission operations, cost 
efficiency, lessons learned 

1. INTRODUCTION 

Remote sensing missions, including 
both missions that explore beyond the 
terrestrial environment and those 
which use space as a vantage point 
from which to study earth, provide us a 
growing experience base in the design 
of mission operations systems (MOS). 


The evolution of MOS designs has 
certainly been a benefit to the later 
projects, allowing them to concentrate 
more on research goals and somewhat 
less on the questions of how the basic 
spacecraft and mission will operate. 
This collective experience allows us to 
learn from our past successes and 
failures and gives us the possibility to 
reduce the operations costs of future 
missions from the lessons that the past 
provides. 

In an attempt to document that 
experience base, several recent 
missions have conducted after-the-fact 
reviews of their mission operations, 
commonly known as "Lessons Learned" 
reviews. The purpose of such reviews 
has been to review the mission's 
performance and to record those 
elements that were either (1) done in a 
way worth recommending to future 
missions or (2) done in a less-than- 
optimum way and worthy of comment 
to allow future missions to correct the 
approach. Within the reports from 
these were many suggestions for 
improvement of cost efficiency in the 
mission operations system. 

This paper results from an 
examination of Lessons Learned 
reviews for topics relating to cost. As 
such, it is a compilation of suggestions 
from the project team members who 
operate at the "worker" level as to how 
future projects might perform their 
tasks with higher productivity and 
lower overall cost. Inputs consisted of 
published Lessons Learned reports 
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from the UARS (Ref. 1) and Magellan 
(Ref. 2) projects, and less formal 
presentations and reports from 
Voyager and Galileo. Individual 
lessons that dealt with operations, ops 
management, or ops development were 
entered into a database and rated for 
their relevance to cost reduction. 
Suggestions were assigned to one or 
more of three mission phases: 
requirements definition; development, 
test and training; and operations. The 
database was then sorted for keywords, 
and common subjects were sorted 
according to the number of entries. 

This report is a compilation of the most 
often-mentioned subjects taken from 
that database. 

Suggestions fell into two categories: 
those thought to increase mission 
success or to reduce risk, and those 
with potential contributions to 
reduction of cost. A total of 1 86 
individual suggestions were related to 
cost savings. After sorting, 27 
comments were found applicable to the 
requirements definition phase, 140 to 
development, test and training, and 90 
to operations. In the following 
sections we summarize the content of 
"the comments made concerning each 
phase. 

2. REQUIREMENTS DEFINITION PHASE 
LESSONS 

For the purposes of this paper we 
define the requirements definition 
phase as the period from project 
inception to the beginning of 
implementation, including any studies 
or preliminary definition steps. Chief 
among cost concerns in this phase 
were familiarity of both the details and 
the intent of requirements and 
continuing interaction with users to 
ensure that the requirements were 
well understood. 

The most frequently mentioned topics 
relevant to the requirements 
definition phase suggested early 
achievement of a clear high-level 


understanding of the goals, scope, and 
risk acceptance criteria envisioned by 
the project before beginning the 
process of writing requirements. This 
conceptual understanding should then 
be modified considering available 
resources. All projects in the study 
mentioned this issue. A similar set of 
comments suggested earlier 
involvement by representatives of 
spacecraft developers, science users, 
and operations designers in a mission 
definition document, which was 
variously referred to as a "Project 
Plan" or "Operations Concept" (Refs. 3, 
4). The UARS document in particular 
recommended the development of a 
"realistic and affordable project plan" 
as a potential cost saver, specifying 
both local and remote facility designs 
as cost drivers to be understood early 
in the definition stage. 

Next in number of recommendations in 
this phase was the subject of software 
requirements. UARS and Magellan 
suggested that software documentation 
such as Software Management and 
Development Plans and Users Guides be 
outlined prior to software definition to 
save redesign during implementation. 
Voyager suggested that earlier 
involvement of multimission 
representatives in requirements 
writing would save downstream costs. 
Magellan also cautioned that a cost- 
related tradeoff exists between the 
effort spent on completing 
requirements definition and that 
required for testing of partial software 
deliveries. 

Recommendations from UARS and 
Magellan suggested that consideration 
of computer loading needs (e. g., disk 
space, CPU speed, and workstation 
sizing) as a fundamental requirement 
would have saved later expenditures to 
re-size processing systems that were 
specified without proper forethought. 
UARS also noted that ground data 
systems should be designed to 
accommodate expansion. 
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Magellan and UARS both commented 
that archiving requirements had not 
been sufficiently considered in the 
original levying of requirements, and 
that excessive resources were required 
to satisfy the projects' archiving 
obligations during the operations 
phase. Both projects benefited from a 
Data Management Plan which 
described archiving and dissemination 
designs, and UARS suggested that such 
a plan should be kept updated as the 
mission matures. 

An unusual suggestion was made in the 
Magellan Lessons Learned that 
projects should as a matter of course 
perform an exercise following 
requirements definition wherein all 
requirements writers would be asked to 
identify those requirements that would 
be deleted should the project be 
required to halve its runout cost (an 
approximation of the descoping 
activity that created Magellan from its 
predecessor, VOIR). Such an exercise, 
done early in the design might be 
useful should actual descoping be 
necessary and, according to its author, 
could identify requirements that were 
less than critical. 

Projects were unanimous in their 
belief that clear, concise requirements 
are a cost saver. Requirements must be 
written "clearly, completely and 
testably," and they must be "fully 
understood, identified and validated." 
More system engineering effort was 
recommended in the early phases of 
project definition. UARS and Magellan 
felt that system engineers needed 
authority over definition 
documentation, and that more science 
involvement would have avoided 
misstatement of resource 
requirements. These two projects also 
commented on the costs of technology 
development, and stated that proven 
system elements should be inherited, 
subject to several development caveats 
regarding inheritance of 
documentation and test data. Care was 
also advised to ensure that revision of 


inherited software or hardware did not 
outweigh the original cost savings. 

3. DEVELOPMENT PHASE LESSONS 

We define the development phase as 
the time period beginning with 
production of a set of complete or 
nearly-complete requirements. In this 
phase the requirements are 
implemented by, for example, writing 
software, building flight hardware, or 
writing procedures and plans. 

Included in this phase are software 
and hardware test and integration and 
personnel training. The largest 
number of comments in the database 
concerned this phase. 

Magellan, UARS and Voyager 
suggested that tests of various 
subsystems could be combined to save 
resources. UARS further suggested 
that coordination and more 
documentation of test requirements 
across support groups was indicated. 
Magellan and UARS both felt that 
earlier testing with dataflow, either 
real or simulated, would have saved 
overall costs. Training costs could be 
saved according to UARS and Magellan 
if simulators used for test and training 
could serve double duty as simulators 
for sequence validation during 
operations, and as substitutes for 
subsystems not yet ready in system- 
level tests. 

Development-phase efficiency could 
also be improved with a clearer overall 
concept document, according to most 
projects. Specifically, Voyager 
referred to earlier involvement of 
multimission, project-specific 
operations and science personnel, and 
asked for more internal reviews. 
Magellan mentioned simultaneous 
design of mission, spacecraft and 
mission operations system, and UARS 
suggested that development of ground 
data systems should consider flight 
operations design. 
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Establishment and control of 
interfaces have been considered key to 
the effective MOS design (Ref. 4). 

Early identification of, 
characterization of, and agreement to 
interfaces was mentioned by three 
projects in this study. Identification of 
single points of contact for each 
interface was thought valuable by 
Voyager. Formal Software Interface 
Specification documents (SISs) were 
thought worthwhile by Magellan 
despite the unexpected effort required. 
Voyager also suggested that all parties 
be required to sign interface 
agreements. Magellan also indicated 
that many paper interfaces could be 
replaced by an electronic mail system. 

The subject of change control was 
popular at Lessons Learned reviews. A 
tighter link between the entity that 
approves changes and the one that 
commits resources was mentioned by 
both Galileo and Magellan as a way of 
avoiding wasted time and thus funds. 
Galileo and UARS suggested that all 
requested changes to requirements be 
thoroughly evaluated by system 
engineers to avoid forgotten impacts. 
The Galileo project, which was forced 
to undergo several major design 
changes prior to its launch, indicated 
that changes must be documented and 
widely distributed when redesign 
occurs, and that the rationale for 
changes should be archived as well. 

Another popular subject was that of 
the formal review process used by most 
NASA missions. Reviews were seen as 
necessary and beneficial by all 
projects, although the comment was 
made that the resources necessary for 
reviews need to be better anticipated. 
Independent design and analysis 
reviews were thought to be effective, 
as were design and interface 
"walkthroughs," and informal 
discussions prior to formal reviews 
Involvement of flight controllers in 
sequence design reviews was thought 
by Voyager personnel to be an aid to 
avoidance of costly command errors. 


Contingency plans are usually 
developed prior to beginning 
operations. The projects reviewed 
here produced varied opinions as to 
the tradeoff between development of a 
few contingency plans to a very high 
level (e. g., to the level of a command 
load that could be immediately 
uplinked) and development of a large 
number of contingency plans to a 
relatively low level. It was clear, 
however, that the level of plan 
development was considered to be a 
cost issue, and that the time spent in 
contingency work should be carefully 
balanced against acceptable level of 
risk. 

4. OPERATIONS PHASE LESSONS 

The operations phase includes all 
portions of the mission dedicated to 
actual acquisition of science data. 
Matters concerning science and 
science interfaces were most 
numerous among operations phase 
comments. 

Both UARS and Magellan used a 
working-group approach for both data 
product and uplink interfaces with 
science teams and believed that 
approach saved time. Magellan 
believed that timely release of science 
data, both digital and photoproduct, to 
be effective, with a minimal required 
validation period. Magellan also 
suggested that science investigators' 
involvement in operations and data 
production was beneficial in reducing 
data production costs. Extensive use of 
students and post-graduates in 
operations was seen as a cost saver 
both at the operations center and 
investigators' home institutions. 

Voyager, UARS and Magellan projects 
attempted some form of distributed 
operations to avoid the expense of 
transporting large numbers of 
investigators and/or contractor 
support personnel to the operations 
center. With few exceptions, the 
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response to such "remote" operations 
was positive. Voyager investigators 
were pleased with remote data access, 
but suggested that the access should be 
simpler and easier. Magellan urged 
future projects to emphasize better 
teleconferencing systems, more voice 
nets, and more regular status reports to 
ease the problems encountered with 
their remotely-located spacecraft team. 
UARS similarly commented that good 
communications and frequent 
meetings are beneficial. However, all 
three projects noted that physical 
separation of groups within a center 
was detrimental. 

5. MANAGEMENT AND CONTRACTUAL 
LESSONS 

Several comments in the Lessons 
Learned reviews pertained not to a 
particular phase of a mission but to 
contractual and management issues. 
Both Magellan and UARS felt that 
contracts written with award fees were 
more productive per dollar spent. 
Magellan added that to maintain 
productivity award fees should be 
constructed so that some incentive 
always remains for the contractor. 

Both projects also noted that time could 
be saved by working problems at the 
lowest possible management level. 

6. CONCLUSIONS 

Personnel involved in Lessons Learned 
activities were quite concerned about 
issues relating to productivity and 
cost-consciousness, and made many 
specific suggestions to future projects 
as to how resources could be saved or 
better directed. Surprising numbers of 
topics were found to be common among 
the four projects reviewed here. 

According to our characterization 
scheme, the greatest number of 
comments received related to ( 1 ) 
software requirements placement and 
related development efficiencies, and 
(2) the achievement of a better 
conceptual understanding of the 


mission before or early in the 
requirements definition phase. Issues 
regarding interfaces were second in 
number. Also receiving relatively 
large number of suggestions were 
distribution of facilities, importance of 
reviews and keeping a strong and 
responsible system engineering 
function. 
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